-
Notifications
You must be signed in to change notification settings - Fork 154
Conversation
While all tests are passing, I am not actually able to test functionality on Windows until a few breaking bugs are fixed (#176). Flow typing is also broken - I probably need to add a separate |
While I'm thinking about it, I need to update the dependency pane UI to reflect the new |
@superhawk610 The breaking bugs should be fixed, hope it's testable now!
Hm, I think "queue" would be confusing for users, since they probably aren't thinking about it in terms of queueing an install. I think it can stay as "Add to Project", or maybe "Install", since install implies it'll take some time? |
src/components/AddDependencySearchResult/AddDependencySearchResult.js
Outdated
Show resolved
Hide resolved
Totally ignore this if you're already aware (cause not sure what you're still working on since it's WIP), but I'm getting some errors when testing the functionality when clicking 'Add to Project' and also 'Delete'. The project seems to instantly get added to the dependency list, that seems... not right. And Delete fails entirely with the same sort of error message.
|
@melanieseltzer yeah, UI integration was the WIP part 😁 If it makes you feel any better, I just flat-out don't have a dependencies pane in my current revision, so it's safe to say there's a bit left to do there. Thanks for the gif, that gives me a good place to start. |
0f4a7ed
to
01b4496
Compare
Alright, the UI is up to date with the rest of the PR and it should be entirely functional. The only visual bug, the Delete button in the dependency management pane, is detailed in #187. |
@superhawk610 Sick 👌 I haven't had a chance to look at the code, but one thing I noticed with the UI is that if I queue up three or more installs, once the first finishes installing and the spinner stops, the remaining will immediately all at once switch to 'Installing' instead of maintaining the queue. |
And some stuff related to #187 I think... |
That's intended 😊 Instead of installing all dependencies serially ( |
Omg this is great 🎉🎉🎉🎉🎉🎉🎉Haven't looked at the code yet, just tried it locally, and it's such a better experience omg. One UX thought: I wonder if we need to expose the idea of a queue at all to the user... Right now there's a clear difference between a dependency queued to install, and one installing. As you're all too familiar, there's a good reason for this difference, but I'm not convinced the user has to know. Maybe we should treat all queued and installing dependencies the same, saying that they're all "installing"? The one weird thing about that is that they'll finish at different times (the very first dependency will finish, and then all the rest in a batch), but I think that's ok! But yeah, no change necessary. I'm not convinced my suggestion is good (I'd love to hear from @melanieseltzer and others!), and even if it is, it's easily something that can be addressed later in another PR. I also noticed the issues that @melanieseltzer brought up; there's some weird double-button thing happening when it's queued, and a similar issue when it's deleting. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Phew! Made it through.
I didn't review the tests very thoroughly, but otherwise I gave it a good pass, ran everything locally. Overall it looks great!
I did have some questions and some suggested changes, though. Let me know if any of my suggestions aren't practical.
The only bugs I found were the ones Melanie caught. I think they can be dealt with in a subsequent PR though, shouldn't be blocking.
Excited to see this land, it's such a better experience!
src/components/AddDependencySearchResult/AddDependencySearchResult.js
Outdated
Show resolved
Hide resolved
src/components/AddDependencySearchResult/AddDependencySearchResult.js
Outdated
Show resolved
Hide resolved
src/components/DeleteDependencyButton/DeleteDependencyButton.js
Outdated
Show resolved
Hide resolved
src/components/DependencyManagementPane/DependencyManagementPane.js
Outdated
Show resolved
Hide resolved
src/components/DependencyManagementPane/DependencyManagementPane.js
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yayyy this looks great! Thanks so much for making all the requested changes :)
}; | ||
|
||
type State = { | ||
[projectId: string]: Array<QueueEntry>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yay, you caught that my suggestion was missing the Array<>
haha
- update dependencies reducer and tests - add queue reducer and tests - move snapshots to separate directory - add `queued-` statuses
- update depedency saga tests - add loadProjectDependencies to read-from-disk.service
- update tests to reflect structural changes - exclude `queue` state from redux-storage
6afbcc3
to
799beb5
Compare
Related Issue: #33
Related PR: #103
Summary:
Currently, installing/updating/deleting a dependency locks that project and blocks further actions until it has completed. This is a huge hindrance to common tasks like installing multiple dependencies, but due to the way package managers work it's generally a bad idea (read: impossible) to perform multiple
yarn add
s or the like in parallel.This PR changes the way dependencies are installed/uninstalled - projects are never locked within the UI, instead creating queued actions when the user attempts to change a dependency while another dependency action is aleady in progress. Since multiple dependencies can be installed/uninstalled with a single command (
yarn add foo bar baz
), we can batch together queued actions while we wait for the active commands to complete.The major breaking changes in this PR include:
queue.reducer.js
: This reducer takes the place ofpackage-json-locked.reducer.js
. When an action would change a dependency while another is already in progress, it is instead pushed into that project's queue. (NOTE: if you still need to check if that project'spackage.json
is locked, this reducer exports a selectorgetPackageJsonLockedForProjectId
that functions exactly as it did previously.)package.json
is locked since that logic is handled bydependency.saga.js
.